The mobile industry is moving towards the next generation technology with better performance and throughput to support traffic such as real-time broadband streaming services. One of such technologies that is gaining most support from the industry is LTE (long term evolution) defined by 3GPP and pursued at 3GPP2 as well.
LTE provides a flatter architecture with less network nodes between a user and a destination, together with bigger throughput to support broadband traffic. FIG. 1 is a block diagram illustrating the LTE architecture. As shown in FIG. 1, there could be only two nodes between user equipment (UE) (e.g., UEs 101-102) and the services (e.g., eNodeB or eNB 103), and a serving gateway (Serving GW or SGW) 107 and a packet data network gateway (PDN-GW) 108. Serving GW 107 terminates the interface from and towards evolved universal mobile telecommunications system (UMTS) terrestrial radio access network (RAN) (E-UTRAN) and provides connectivity to PDN-GW 108, which is coupled to operator services node 109 and the Internet 110. Serving GW 107 acts as a mobility anchor for inter-eNB handover and intra-3GPP handover between 3G and LTE. Mobile management entity (MME) 106 is responsible for authentication and critical management for mobile devices as well as for tracking and paging procedures for mobiles in the idle mode. MME 106 authorizes bearer activation and/or deactivation including SGW and PDN GW selection. PDN GW 108 is the permanent IP point-of attachment for access via the E-UTRAN. PDN DW 108 performs IP policy and charging enforcement on packet flows to and from UEs.
The LTE architecture also assumes all-Internet protocol (IP) infrastructure in the network. In this all-IP environment, it is possible and desirable to use the lowest cost IP transport from any provider as the backhaul for E-UTRAN. This reduces the backhaul cost from the operators, but it also introduces a security and privacy issue where an operator's assets (e.g., eNB 103, core network 105) become vulnerable to attacks from the open IP network. Moreover, the confidentiality of signaling and management information may also be lost. In order to address these issues, in some of the deployment scenarios, eNB 103 is made as a secure end point and a security gateway (Security GW or SeGW) 104 is located at the edge of the operator network 105 to secure both ends and provides adequate service level agreements (SLAs).
As shown in FIG. 1, the security gateway 104 is located at the edge of the operator's core network 105 and establishes IP security (IPsec) security association (SA) with eNB 103. This ensures that the traffic that is passing between the eNB 103 and the core network nodes (e.g., SGW 107) is secured based on the operator's policy while operators benefit from the least cost open IP transport. For example, traffic between eNB 103 and Serving GW 107 over S1-U interface is securely protected over open IP transport.
This architecture provides the flexibility, efficiency, and security to the operators. However, the introduction of IPsec means additional IPsec overhead between eNB 103 and the security GW 104. As eNB 103 needs to support many UEs residing in its area, the IPsec needs to operate in a tunnel mode, which requires significant overhead processes.
FIG. 2 is a diagram illustrating typical packet processes between an eNB node and Security GW in a tunnel mode. When eNB 103 receives a packet 201 from a UE to send toward the core network (CN), eNB 103 encapsulates packet 201 in another packet 202 constructed as per protocols relevant to the S1 interface and then sends it to Serving GW 104. This is composed of IP header 204 (with source IP address of eNB 103 and destination IP address of Serving GW 104), the UDP header and GPRS tunneling protocol (GTP) payload as a whole referred to as a payload 205, which contains the UE's IP address and the destination IP address. With the overlaid security, the S1 packet needs to be sent inside an IPsec tunnel. Thus, eNB 103 adds an ESP trailer 208 to the S1 packet and the S1 packet itself (including IP header 204, UDP header and GTP 205, and ESP trailer 208) is encrypted. Then the ESP header 207 and ESP authenticator 209 is added as well as the outer IP header 206 having source IP address of eNB 103 and the destination IP address of Security GW 104. When Security GW 104 receives the encrypted packet 202, it removes all the IPsec related headers and extracts the S1 packet 203 (i.e. inner IP header, UDP header, and GTP) to forward packet 203 to the IP destination, i.e. Serving GW 107.
Even if the open IP transport provides cost effectiveness and flexibility, the tunnel inside another tunnel scenario as described above would lower the total throughput as well as may cause unnecessary fragmentation and reassembly, especially, when an operator moves from its own backhaul to an open backhaul network.
ESP is a member of IPsec protocol suite. In IPsec it provides origin authenticity, integrity, and confidentiality protection of packets. ESP does not protect the IP packet header. However, in a tunnel mode, where the entire origin IP packet (e.g., packet 201) is encapsulated with a new packet header (e.g., outer IP header 206) added, ESP protection is afforded to the whole inner IP packet (including the inner IP header 204) while the outer header remains unprotected. ESP operates directly on top of IP.